Coders make resolutions, no? If your to-do-better list is still empty, consider these ideas from other programmers to put to use in the New Year. Even the smartest folks have room to grow. The following excerpts are contained in the book 97 Things Every Programmer Should Know edited by Kevlin Henney. Check Your Code First Before Looking to Blame Others Continuous Learning Don’t Be Afraid to Break Things The Professional Programmer Take Advantage of Code Analysis Tools Ubuntu Coding for Your Friends You Gotta Care About the Code
1. Check Your Code First Before Looking to Blame Others Question your own assumptions and the assumptions of others. Tools from different vendors might have different assumptions built into them so too might different tools from the same vendor. When someone else is reporting a problem you cannot duplicate, go and see what they are doing. They may be doing something you never thought of or are doing something in a different order. My personal rule is that if I have a bug I can’t pin down, and I’m starting to think it’s the compiler, then it’s time to look for stack corruption. This is especially true if adding trace code makes the problem move around. Multithreaded problems are another source of bugs that turn hair gray and induce screaming at the machine. All the recommendations to favor simple code are multiplied when a system is multithreaded. Debugging and unit tests cannot be relied on to find such bugs with any consistency, so simplicity of design is paramount. So, before you rush to blame the compiler, remember Sherlock Holmes’s advice, “Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth,” and opt for it over Dirk Gently’s, “Once you eliminate the improbable, whatever remains, no matter how impossible, must be the truth.” —Allan Kelly

2. Continuous Learning We live in interesting times. As development gets distributed across the globe, you learn there are lots of people capable of doing your job. You need to keep learning to stay marketable. Otherwise you’ll become a dinosaur, stuck in the same job until, one day, you’ll no longer be needed or your job gets outsourced to some cheaper resource. So what do you do about it? Some employers are generous enough to provide training to broaden your skill set. Others may not be able to spare the time or money for any training at all. To play it safe, you need to take responsibility for your own education. Here’s a list of ways to keep you learning. Many of these can be found on the Internet for free: Read books, magazines, blogs, Twitter feeds, and websites. If you want to go deeper into a subject, consider joining a mailing list or newsgroup. If you really want to get immersed in a technology, get hands on—write some code. Always try to work with a mentor, as being the top guy can hinder your education. Although you can learn something from anybody, you can learn a whole lot more from someone smarter or more experienced than you. If you can’t find a mentor, consider moving on. Use virtual mentors. Find authors and developers on the Web who you really like and read everything they write. Subscribe to their blogs. Get to know the frameworks and libraries you use. Knowing how something works makes you know how to use it better. If they’re open source, you’re really in luck. Use the debugger to step through the code to see what’s going on under the hood. You’ll get to see code written and reviewed by some really smart people. Whenever you make a mistake, fix a bug, or run into a problem, try to really understand what happened. It’s likely that someone else ran into the same problem and posted it on the Web. Google is really useful here. A good way to learn something is to teach or speak about it. When people are going to listen to you and ask you questions, you’ll be highly motivated to learn. Try a lunch-’n’-learn at work, a user group, or a local conference. Join or start a study group (à la patterns community) or a local user group for a language, technology, or discipline you are interested in. Go to conferences. And if you can’t go, many conferences put their talks online for free. Long commute? Listen to podcasts. Ever run a static analysis tool over the codebase or look at the warnings in your IDE? Understand what they’re reporting and why. Follow the advice of the Pragmatic Programmers* and learn a new language every year. At least learn a new technology or tool. Branching out gives you new ideas you can use in your current technology stack. Not everything you learn has to be about technology. Learn the domain you’re working in so you can better understand the requirements and help solve the business problem. Learning how to be more productive—how to work better—is another good option. Go back to school. It would be nice to have the capability that Neo had in The Matrix, and simply download the information we need into our brains. But we don’t, so it will take a time commitment. You don’t have to spend every waking hour learning. A little time—say, each week—is better than nothing. There is (or should be) a life outside of work. Technology changes fast. Don’t get left behind. —Clint Shank

3. Don’t Be Afraid to Break Things Everyone with industry experience has undoubtedly worked on a project where the codebase was precarious at best. The system is poorly factored, and changing one thing always manages to break another unrelated feature. Whenever a module is added, the coder’s goal is to change as little as possible, and hold his breath during every release. This is the software equivalent of playing Jenga with I-beams in a skyscraper, and is bound for disaster. The reason that making changes is so nerve-racking is because the system is sick. It needs a doctor, otherwise its condition will only worsen. You already know what is wrong with your system, but you are afraid of breaking the eggs to make your omelet. A skilled surgeon knows that cuts have to be made in order to operate, but she also knows that the cuts are temporary and will heal. The end result of the operation is worth the initial pain, and the patient should heal to a better state than he was in before the surgery. Don’t be afraid of your code. Who cares if something gets temporarily broken while you move things around? A paralyzing fear of change is what got your project into this state to begin with. Investing the time to refactor will pay for itself several times over the lifecycle of your project. An added benefit is that your team’s experience dealing with the sick system makes you all experts in knowing how it should work. Apply this knowledge rather than resent it. Working on a system you hate is not how anybody should have to spend his time. Redefine internal interfaces, restructure modules, refactor copy-pasted code, and simplify your design by reducing dependencies. You can significantly reduce code complexity by eliminating corner cases, which often result from improperly coupled features. Slowly transition the old structure into the new one, testing along the way. Trying to accomplish a large refactor in “one big shebang” will cause enough problems to make you consider abandoning the whole effort midway through. Be the surgeon who isn’t afraid to cut out the sick parts to make room for healing. The attitude is contagious and will inspire others to start working on those cleanup projects they’ve been putting off. Keep a “hygiene” list of tasks that the team feels are worthwhile for the general good of the project. Convince management that even though these tasks may not produce visible results, they will reduce expenses and expedite future releases. Never stop caring about the general “health” of the code. —Mike Lewis

4. The Professional Programmer The single most important trait of a professional programmer is personal responsibility. Professional programmers take responsibility for their career, their estimates, their schedule commitments, their mistakes, and their workmanship. A professional programmer does not pass that responsibility off on others. If you are a professional, then you are responsible for your own career. You are responsible for reading and learning. You are responsible for staying up to date with the industry and the technology. Too many programmers feel that it is their employer’s job to train them. Sorry, this is just dead wrong. Do you think doctors behave that way? Do you think lawyers behave that way? No, they train themselves on their own time, and their own nickel. They spend much of their off-hours reading journals and decisions. They keep themselves up to date. And so must we. The relationship between you and your employer is spelled out nicely in your employment contract. In short: your employer promises to pay you, and you promise to do a good job. Professionals take responsibility for the code they write. They do not release code unless they know it works. Think about that for a minute. How can you possibly consider yourself a professional if you are willing to release code that you are not sure of? Professional programmers expect QA to find nothing because they don’t release their code until they’ve thoroughly tested it. Of course, QA will find some problems, because no one is perfect. But as professionals, our attitude must be that we will leave nothing for QA to find. Professionals are team players. They take responsibility for the output of the whole team, not just their own work. They help one another, teach one another, learn from one another, and even cover for one another when necessary. When one teammate falls down, the others step in, knowing that one day they’ll be the ones to need cover. Professionals do not tolerate big bug lists. A huge bug list is sloppy. Systems with thousands of issues in the issue-tracking database are tragedies of carelessness. Indeed, in most projects, the very need for an issue-tracking system is a symptom of carelessness. Only the very biggest systems should have bug lists so long that automation is required to manage them. Professionals do not make a mess. They take pride in their workmanship. They keep their code clean, well structured, and easy to read. They follow agreed-upon standards and best practices. They never, ever rush. Imagine that you are having an out-of-body experience watching a doctor perform open-heart surgery on you. This doctor has a deadline (in the literal sense). He must finish before the heart-lung bypass machine damages too many of your blood cells. How do you want him to behave? Do you want him to behave like the typical software developer, rushing and making a mess? Do you want him to say, “I’ll go back and fix this later”? Or do you want him to hold carefully to his disciplines, taking his time, confident that his approach is the best approach he can reasonably take. Do you want a mess, or professionalism? Professionals are responsible. They take responsibility for their own careers. They take responsibility for making sure their code works properly. They take responsibility for the quality of their workmanship. They do not abandon their principles when deadlines loom. Indeed, when the pressure mounts, professionals hold ever tighter to the disciplines they know are right. —Robert C. Martin (Uncle Bob)

5. Take Advantage of Code Analysis Tools The value of testing is something that is drummed into software developers from the early stages of their programming journey. In recent years, the rise of unit testing, test-driven development, and agile methods has attested to a surge of interest in making the most of testing throughout all phases of the development cycle. However, testing is just one of many tools that you can use to improve the quality of code. Back in the mists of time, when C was still a new phenomenon, CPU time and storage of any kind were at a premium. The first C compilers were mindful of this and so cut down on the number of passes through the code they made by removing some semantic analyses. This meant that the compiler checked for only a small subset of the bugs that could be detected at compile time. To compensate, Stephen Johnson wrote a tool called lint—which removes the fluff from your code—that implemented some of the static analyses that had been removed from its sister C compiler. Static analysis tools, however, gained a reputation for giving large numbers of false-positive warnings and warnings about stylistic conventions that aren’t always necessary to follow. The current landscape of languages, compilers, and static analysis tools is very different. Memory and CPU time are now relatively cheap, so compilers can afford to check for more errors. Almost every language boasts at least one tool that checks for violations of style guides, common gotchas, and sometimes cunning errors that can be hard to catch, such as potential null pointer dereferences. The more sophisticated tools, such as Splint for C or Pylint for Python, are configurable, meaning that you can choose which errors and warnings the tool emits with a configuration file, via command-line switches, or in your IDE. Splint will even let you annotate your code in comments to give it better hints about how your program works. If all else fails, and you find yourself looking for simple bugs or standards violations that are not caught by your compiler, IDE, or lint tools, then you can always roll your own static checker. This is not as difficult as it might sound. Most languages, particularly ones branded dynamic, expose their abstract syntax tree and compiler tools as part of their standard library. It is well worth getting to know the dusty corners of standard libraries that are used by the development team of the language you are using, as these often contain hid-den gems that are useful for static analysis and dynamic testing. For example, the Python standard library contains a disassembler which tells you the bytecode used to generate some compiled code or code object. This sounds like an obscure tool for compiler writers on the python-dev team, but it is actually surprisingly useful in everyday situations. One thing this library can disassemble is your last stack trace, giving you feedback on exactly which bytecode instruction threw the last uncaught exception. So, don’t let testing be the end of your quality assurance—take advantage of analysis tools, and don’t be afraid to roll your own. —Sarah Mount

6. Ubuntu Coding for Your Friends So often, we write code in isolation and that code reflects our personal interpretation of a problem, as well as a very personalized solution. We may be part of the team, yet we are isolated, as is the team. We forget all too easily that this code created in isolation will be executed, used, extended, and relied upon by others. It is easy to overlook the social side of software creation. Creating software is a technical exercise mixed into a social exercise. We just need to lift our heads more often to realize that we are not working in isolation, and we have shared responsibility for increasing the probability of success for everyone, not just the development team. You can write good-quality code in isolation, all the while lost in self. From one perspective, that is an egocentric approach (not ego as in arrogant, but ego as in personal). It is also a Zen view and it is about you, in that moment of creating code. I always try to live in the moment because it helps me get closer to good quality, but then I live in my moment. What about the moment of my team? Is my moment the same as the team’s moment? In Zulu, the philosophy of Ubuntu is summed up as “Umuntu ngumuntu ngabantu,” which roughly translates to “A person is a person through (other) persons.” I get better because you make me better through your good actions. The flip side is that you get worse at what you do when I am bad at what I do. Among developers, we can narrow it down to “A developer is a developer through (other) developers.” If we take it down to the metal, then “Code is code through (other) code.” The quality of the code I write affects the quality of the code you write. What if my code is of poor quality? Even if you write very clean code, it is at the points where you use my code that your code quality will degrade to close to the quality of my code. You can apply many patterns and techniques to limit the damage, but the damage has already been done. I have caused you to do more than what you needed to do, simply because I did not think about you when I was living in my moment. I may consider my code to be clean, but I can still make it better just by Ubuntu coding. What does Ubuntu code look like? It looks just like good, clean code. It is not about the code, the artifact. It is about the act of creating that artifact. Coding for your friends, with Ubuntu, will help your team live your values and reinforce your principles. The next person that touches your code, in whatever way, will be a better person and a better developer. Zen is about the individual. Ubuntu is about Zen for a group of people. Very, very rarely do we create code for ourselves alone. —Aslam Khan

7. You Gotta Care About the Code It doesn’t take Sherlock Holmes to work out that good programmers write good code. Bad programmers…don’t. They produce monstrosities that the rest of us have to clean up. You want to write the good stuff, right? You want to be a good programmer. Good code doesn’t pop out of thin air. It isn’t something that happens by luck when the planets align. To get good code, you have to work at it. Hard. And you’ll only get good code if you actually care about good code. Good programming is not born from mere technical competence. I’ve seen highly intellectual programmers who can produce intense and impressive algorithms, who know their language standard by heart, but who write the most awful code. It’s painful to read, painful to use, and painful to modify. I’ve seen more humble programmers who stick to very simple code, but who write elegant and expressive programs that are a joy to work with. Based on my years of experience in the software factory, I’ve concluded that the real difference between adequate programmers and great programmers is this: attitude. Good programming lies in taking a professional approach, and wanting to write the best software you can, within the real-world constraints and pressures of the software factory. The code to hell is paved with good intentions. To be an excellent programmer, you have to rise above good intentions, and actually care about the code—foster positive perspectives and develop healthy attitudes. Great code is carefully crafted by master artisans, not thoughtlessly hacked out by sloppy programmers or erected mysteriously by self-professed coding gurus. —Pete Goodliffe Wishing you all the best in 2014.